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NASA Goddard Space Flight Center’s Space Science Mission Operations (SSMO) 
Project is currently tackling the challenge of minimizing ground operations costs for 
multiple satellites that have surpassed their prime mission phase and are well into extended 
mission. These missions are being reengineered into a multi-mission operations center built 
around modern information technologies and a common ground system infrastructure. The 
effort began with the integration of four SMEX missions into a similar architecture that 
provides command and control capabilities and demonstrates fleet automation and control 
concepts as a pathfinder for additional mission integrations. The reengineered ground 
system, called the Multi-Mission Operations Center (MMOC), is now undergoing a 
transformation to support other SSMO missions, which include SOHO, Wind, and ACE. 
This paper presents the automation principles and lessons learned to date for integrating 
automation into an existing operations environment for multiple satellites. 


I. Introduction 

N ASA Goddard Space Flight Center’s Space Science Mission Operations (SSMO) Project has several satellites 
that are past their prime phases and well into extended mission operations. These missions continue to produce 
valuable science measurements and useful engineering data. Mission extensions are determined by a competitive 
review process that considers the science per dollar return. In an effort to reduce the operations cost, the SSMO 
Project is seeking to integrate several missions into a single Multi-Mission Operations Center that can be operated 
with a reduced staff through the application of various automation techniques. 

The MMOC will provide a centralized engineering facility responsible for the health and safety monitoring of 
several heterogeneous satellites managed by the SSMO organization. Ultimately, the MMOC will allow the SSMO 
missions to maintain their proactive approach to preventing on-orbit problems while minimizing the cost of 
defining, implementing, and sustaining the operational environment. 

One benefit of the MMOC is a higher level of interoperability and collaboration among the participating 
missions. Several of these missions already have common characteristics. Having similar satellite architectures and 
software components allowed some missions like SMEX, to be grouped together within the same facility and 
operated by cross-trained Flight Operations Teams (FOT). This resulted in mission operation centers (MOC) that 
were capable of housing two or more missions, but had limited shared resources beyond the FOT. Notwithstanding, 
future missions are able to benefit by leveraging the knowledge and experiences gained by the FOT across missions 
and managing their technological risks. The SSMO Project is planning to further leverage the economies of scale by 
building upon the existing capabilities of the MMOC with a newfound emphasis on consolidating similar functions 
across dissimilar missions. The previous SSMO Project paradigm showed that sharing personnel and knowledge in 
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a single facility was beneficial, but the current MMOC is planning to show that sharing software components within 
a common architecture across missions will provide an even greater number of benefits. 

This paper presents the status of these efforts and summarizes the lessons learned in so doing. The first section 
of the paper describes the current state-of-the-art SMEX MOC that operates the following four satellites: SAMPEX, 
SWAS, TRACE, and WIRE. The current state-of-the-art automation that is being used in the SMEX MMOC to 
control the SWAS, SAMPEX, TRACE, and WIRE spacecraft has been described in previous papers'” and only a 
summary is presented here. The following section describes how the architecture and operations are being adapted 
to incorporate the SOHO, Wind, and ACE missions. The final section of the paper summarizes the conclusions and 
challenges ahead. 


II. Automation in the SMEX MMOC 


A. Background 

The Small Explorer (SMEX) missions are part of NASA’s Explorer program and were specifically designed to 
provide frequent flight opportunities for inexpensive, well-focused science missions. The cost cap for any SMEX 
mission is $120 million total cost to NASA, which includes the definition, development, launch services, mission 
operations, and data analysis aspects of the mission 2 3 . Table 1 summarizes the SMEX missions operated at GSFC, 
and addressed in this paper. 


Table 1 - Characteristics of GSFC SMEX Missions 4 


Satellite 

Launch Date 

Mass 

Orbit 

Operations 

SAMPEX 

July 3, 1992 

157 kg 

550 km x 675 km, 82° 

Two contacts per day, 
12 hours apart 

TRACE 

April 1, 1998 

250 kg 

600 km x 650 km, 
97.80° 

Four - six contacts per day 

SWAS 

December 5, 1998 

288 kg 

637 km x 653 km, 
69.90° 

Two contacts per day, 1 2 hours apart 

WIRE 

March 3, 1 999 

258.7 kg 

540 km x 590 km, 
97.56° 

Two contacts per day, 12 hours apart 


All four missions in Table 1 are well into extended operations. Previous efforts have been made to reduce the 
continuing operating costs of these missions through increasing their level of automation. Advances were made and 
the number of staff required to operate each spacecraft has decreased over the years. 

In order to further reduce the costs of continuing operations for these missions, the SMEX missions are operated 
from a single Multi-Mission Operations Center that controls all four spacecraft. The MMOC is more than just a 
relocation of the individual mission hardware and operators into one room. The four spacecraft use common 
software where effective and utilize automation to reduce the original 24 hour by 7 day (24/7) staffing profile when 
SAMPEX was launched to a single 8 hour shift, 5 days a week (5x8) across all four missions. 

B. GMSEC and the SMEX MMOC 

Beginning in 2004, plans were made to integrate the SAMPEX, SWAS, TRACE, and WIRE ground systems as 
an early demonstration of the GSFC Mission Services Evolution Center (GMSEC) architecture. The GMSEC 
architecture was developed to support greater component interoperability and to infuse modern information 
technologies into both existing and future mission operations. The GMSEC architecture 4 uses commercial Message 
Oriented Middleware and a common messaging standard to provide interoperability of MOC systems and offer 
missions choices during the component selection process and throughout the mission lifecycle. With this 
architecture, GMSEC compliant components can be quickly selected and integrated into the MOC and configured to 
interoperate. Figure 1 shows a number of the software components and applications that have been integrated to 
date to work within the GMSEC environment. The highlighted components are those in use in the SMEX MMOC. 
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Figure 1 - GMSEC Components and Programming Languages with SMEX MMOC Components Highlighted 

The SMEX MMOC is built upon this GMSEC architecture. The components used for the various ground system 
functions are all inter-connected using the GMSEC middleware. The GMSEC architecture provides ground system 
software components with both a means of communication and a common syntax that allows these components to 
exchange and share information. Furthermore, the automation approach of these missions is enabled by the GMSEC 
architecture because all information is readily available for all components in the system. Additionally, components 
can easily direct other components to perform specific functions. Another important aspect of automation is 
maintaining the capability to manually operate the system, especially while troubleshooting spacecraft anomalies or 
handling partial system failures. Around-the-clock handling of routine functions is automated within the GMSEC 
architecture, but the system design approach allows the flight operations team to maintain their proficiency in using 
the system and maintaining operations experience and knowledge of the satellite. 

C. Automation 

To support the reduced budgets of extended life missions, SMEX has adopted a constructive attitude towards the 
use of automation in supporting these missions. The automation technologies supported in SMEX are built upon 
capabilities provided by the GMSEC architecture that allows the FOT to further reduce the involvement of the 
console operator. The FOT staffs a single shift during weekdays, with the automation responsible for two shifts per 
day and the entire weekend. The primary focus for automation traditionally has been real-time health and safety 
monitoring of the satellites, with a secondary emphasis on the offline automation. The design of the SMEX MMOC 
has introduced automation into almost all areas of mission operations. Most of the FOT functions are now able to be 
completely automated. The only areas that have not been fully automated are command table generation and 
upload, fault detection, identification, and resolution (which includes trending), contact scheduling, and maneuver 
planning. (Note that for the SMEX spacecraft, maneuver planning only includes attitude maneuvers.) The 
following sections describe the automation used in various mission operations areas in the SMEX MMOC. 

/. Telemetry and Commanding and Data Archive 

Since reduction from a 24/7 operations concept, the SMEX missions have utilized the GSFC-developed 
telemetry and command (T&C) system Integrated Test and Operations System (ITOS). As a precursor to full 
implementation of a MMOC, the InControl-NG (INCNG) multi-satellite telemetry and command (T&C) system 
product developed by L3 has been integrated into the SMEX environment and has been demonstrated operationally 
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by SWAS and TRACE. INCNG has a suite of services that provide support for multiple missions simultaneously 
from a single system, while providing the flight operations team (FOT) with multiple interfaces to access and 
control any of the missions from within the MOC. A fleet view provides the operators with an overall health display 
while alpha-numeric displays provide the FOT with satellite specific pages for monitoring telemetry. For the SMEX 
MMOC, INCNG is also providing the data archive functionality. 

INCNG has a built-in scheduler that enables all of the activities associated with ground station contacts to be 
automated. The INCNG integrated scheduler is used to provide both time and event driven automation of the 
contacts. The contact schedules generated by the external scheduling group are translated into a format suitable for 
ingest by the INCNG scheduler. This task is completed by an external GMSEC component called the White Sands 
Automated Scheduler (WSAS). INCNG then invokes a pre-pass procedure approximately 20 minutes prior to signal 
acquisition to setup for the support. During the support, commands for transmitting the command loads and for 
resetting the inactivity timer are executed by a procedure scheduled within the T&C system. Real-time 
decommutation and limit checking is performed by the T&C system, which publishes alert messages via the 
middleware for violations of analog or discrete information. Both the real-time and stored telemetry data are 
archived within INCNG. After the contact is complete, the scheduler runs a procedure that causes INCNG to close 
the communication with the ground station. If a contact fails or in the event the automation fails, the FOT is 
notified. While the automation system will automatically retry for the next contact, no on-demand contact 
scheduling with the ground station is performed at this time. 

Additionally, ITOS is used in the MMOC for the TRACE mission operating from GSFC and for the SAMPEX 
mission operating from an alternative location at the Bowie State University Operations Control Center (BSOCC). 
The capability to operate with multiple T&C systems from the same middleware bus from different physical 
locations demonstrates the flexibility to allow missions to select from a suite of available GMSEC-compliant 
components without hindering interoperability. 

2. Automated Spacecraft Load Management 

Spacecraft load management is the process of building command loads that are to be uplinked to the satellites. 
This is a multi-step process that typically requires multiple applications to complete. Example inputs to the 
command load set include ground station schedules, products from flight dynamics, science observation timelines 
and other sources. The assembling of the integrated command load is still performed manually, but making sure the 
load gets to the satellite has been automated. Ground station contact schedules are delivered directly to the MMOC 
by the Ground Network managed centralized scheduling center at White Sands. An application was created to 
monitor and manage these schedules and their updates, to coordinate the INCNG functions to ensure planned 
activities are current and accurate, and to ensure the command load has been sent, or if unsuccessful, to reschedule 
for an appropriate subsequent contact. 

3. Automation Rules and Operator Notification 

When a ground system is supporting multiple missions or is unattended, it can be difficult to diagnose or even 
know when problems or anomalies are occurring. However, the FOT does have the capability to describe such 
events in the form of automation rules. The rules are configured and monitored by the Criteria Action Table (CAT) 
product. The automation rules simply describe the content of any component message that is published on the 
middleware bus and actions are taken if the rules are met. Since every component publishes its log messages to the 
middleware, virtually any event can be captured. The most typical action taken is to notify an operator with an 
email or page. The notifications are sent using the Alert Notification/System Router (ANSR) product, which is a 
highly reliable system with full redundancy and operates within the strict security guidelines of GSFC. 

4. Automated Flight Dynamics System 

Flight dynamics products need to be generated on a routine basis to assist with mission planning activities. The 
primary prerequisite to running a flight dynamics product generation session is an ephemeris file for the satellite. If 
the space network is being used, Tracking Data Relay Satellite (TDRS) ephemeredes will be required as well. When 
all inputs are available, the flight dynamics system generates the products, validates them, and then delivers them to 
various customers. 

The generation of various flight dynamics products has been automated using GSFC’s X-Flight Dynamics 
System (XFDS). XFDS is a flight dynamics automation system used for daily product generation that was 
originally developed for the Terra mission and used by many other GSFC missions. It interfaces with the Satellite 
Tool Kit (STK) and other external products to generate raw products, capture those raw products, reformat, and 
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validate them. Once the products are generated or an error has been encountered, XFDS publishes notification 
messages to the middleware to alert other subsystems, 

5. Spacecraft Health and Safety Monitoring 

During ground station contacts, the FOT relies on multiple levels of automation to monitor spacecraft safety. 
Real-time limit checking of telemetry data is performed by the T&C system, which publishes alert messages via the 
middleware for violations of analog or discrete information. The rule-based engine CAT subscribes to these alerts 
and warnings and takes appropriate actions based on predefined system rules. ANSR is used to send emails and 
pages if the MMOC is not staffed. 

6. Ground System Monitoring 

The scenarios in the previous sections covered cases where functional components are running without 
problems. However, it can be difficult to catch issues or anomalies when components are not publishing error 
messages simply because they are not running. A system was put in place in the MMOC to monitor all aspects of 
the ground system, including the existence and count of expected processes, processor load, and disk and memory 
usage. This system is called Nagios and custom plug-ins were developed to function as a GMSEC adapter. Nagios 
has the capability of monitoring Solaris, Windows, and Linux systems. It also provides a consolidated console that 
displays the health of the entire network of computers and the status of every defined check for the system. System 
monitoring has become an essential component of the MMOC. 

D. Benefits and Lessons Learned 

The SMEX MMOC is now operational for SAMPEX, SWAS, and TRACE. WIRE was excluded for 
programmatic reasons at this time. The FOT staffs the MOC for 8 hours each weekday, but the automation 
generally handles almost all routine tasks. The rest of the time, the automation systems control the spacecraft fully 
and will notify the FOT via pager and/or email if any unexpected circumstances arise. Command uploads are still 
performed by the FOT. 

In addition to this increased level of automation the GMSEC approach supports a more sustainable environment 
since this architecture provides a standard interface that decouples the architecture from the applications. While 
most SSMO missions have incorporated degrees of automation into their nominal operations, the automation 
systems have outlived their cost effectiveness to maintain. The SMEX environment has been used as a proof of 
concept to integrate the rest of the SSMO missions. 

The SMEX MMOC has also proven the ability and flexibility of the GMSEC architecture to easily accommodate 
mission-specific needs or requirements within a common ground system. This is demonstrated by the use of both 
INCNG and ITOS as the T&C system for different missions. 

There are several key lessons learned from the experiences of implementing the SMEX missions into the 
MMOC. These are discussed in greater detail in Reference 1 and summarized below: 

1. Adapting Components for Automation in a GMSEC Environment - Although native GMSEC support is 
preferred; it is sometimes more appropriate to develop a GMSEC adaptor for software components. 

2. Scaling Application - Application scalability is always possible but how it’s done depends on the 
application 

3. Planning for Failover - Failover behaviors should be consistent to obtain predictable behaviors 

4. Maintaining FOT Proficiency - To maintain FOT proficiency, the ground system must be developed to 
run in a manual as well as automated mode, missions must utilize cross-training of tools, and routine 
exercises and certifications must be performed. 

5. Increasing Situational Awareness - As more satellite missions, more software applications, more 
servers, and more facilities are added to the MMOC, more tools to increase situational awareness are 
required to allow the FOT to easily diagnose and troubleshoot problems. 

6. Common Scheduling Component - A common scheduling component helps the FOT to be aware of all 
events taking place in the system and becomes especially important as more satellites are added to the 
MMOC. 

7. Centralized Control Application - A centralized control center application would be useful to better 
manage complex interactions among components. 

8. Dissecting Applications for Reuse - Dissecting an application into separate reusable and mission 
specific GMSEC components can lead to reduced software development and maintenance efforts. 

The current SSMO plan is to expand upon the SMEX architecture and benefit from these lessons learned to 
integrate additional satellites into the MMOC. 
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III. Automation in the SSMO MMOC 

In an effort to minimize lifecycle costs and ensure sustainability for a number of missions, the SSMO Project is 
establishing and implementing a plan to transition operations into a consolidated control center that will leverage 
GMSEC technologies and common software support systems. Currently, the support systems vary by mission; 
however each mission has the same operational functions of health and safety monitoring, commanding, data 
archiving, flight dynamic product generation, and scheduling. Moving towards a consolidated control center with 
shared software systems allows the SSMO Project to address evolving agency regulations as well as reducing the 
software and hardware maintenance costs by reducing the number of mission unique components. The standard 
interfaces and components also enable automation to be implemented in a common fashion (both architecture and 
design principles) across all missions. 

A. Operations in the MMOC 

The goal of the MMOC is to enable the SSMO missions to maintain their proactive approach for prevention of 
on-orbit problems, while minimizing the cost of defining, implementing and sustaining the operational environment. 
It is anticipated that the MMOC will provide a central arena where collaboration and communication take place 
among the participating missions. Using recently developed information technologies, the SSMO Project is able to 
connect distributed mission operation centers across Goddard and its partners, such that these mission operation 
centers behave as if they physically reside within the same facility. Within a two year window, it is expected that 
the Wind, ACE, and SOHO missions will be incorporated into the precursor SMEX MMOC. 

The MMOC will use GMSEC automation tools to operate routine functions. The operations concept for the 
MMOC is to staff the MMOC with only a single day shift, thereby limiting routine staff support to an 8 hour shift 
Monday through Friday. The automation system will perform nominal operations, monitoring for problems and 
publishing an electronic alert message to engineers when problems arise. The operations engineers will continue to 
handle all special operations, as well as any anomalous situations. 

B. Evolving FOT Roles 

Automation does not completely replace the FOT, but is a tool that is used to perform routine and complex 
operations with a high level of confidence, precision and accuracy. As Operations Centers continue to include more 
automation, the role of the EOT will have to change. Instead of manually executing routine pass plans, the FOT will 
be responsible for monitoring, controlling, and enhancing the automation while maintaining operations proficiency. 
The level of support required by the FOT can range from manual control of the system, to oversight of the 
automated functions and management of complex situations, to trouble-shooting of anomalies and installation and 
test of software upgrades. Not only will the FOT need proficiency in the satellites’ major systems, but they will also 
be required to control the ground system and its automation. The FOT will continue to be the critical element in 
supporting operations. 

An important principle being followed in the design of the SSMO MMOC is that the FOT own the automation 
and are responsible for the upkeep and maintenance of the automation logic. The goal is to have the operators with 
the expert knowledge be in control of deploying and maintaining this expertise in the automated system. There are 
several benefits to this approach. The first is the ability of the FOT to improve and evolve automation over time. 
The automation requirements may not be known to the level desired until a system is first implemented or until the 
system is exercised over time. If the automation is “hard-coded” and requires a software developer to make 
automation changes, then costs will be driven up by the additional support fees and multiple iterations necessary to 
deliver a new release of the software. Additionally, this situation would serve to frustrate both the developers and 
the end-users and may not result in the level of automation desired by the operators. The second benefit is the 
ability of the FOT to directly interact with the automation, primarily for troubleshooting and problem diagnosis. 
Any level of automation requires oversight and troubleshooting by the FOT when problems arise. If the 
development philosophy has been that only the application developers can modify the automation, then the FOT is 
constrained by the need to go to the application developer to fix bugs and/or make changes to the level of 
automation. Finally, the authors believe that when the FOT take ownership of the automation, they are more likely 
to readily accept the automation and appreciate the benefits from it. 

Having ownership of the automation is much more than specifying requirements for external developers. It is 
providing the tools and skills to the FOT to manage their automation configuration. An effective means to 
accomplish this is to develop automation based on scripts or procedures that can be managed by the FOT. Another 
means is to provide tools and interfaces that the FOT can use that do not require extensive knowledge of highly 
specialized languages and constructs. These approaches are being used in the development of the SSMO MMOC 
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with the goal of achieving eighty to ninety percent of the desired level of automation through these means. It is 
understood that not all automation can be scripted or placed in an editable configuration file, but all steps will be 
taken to maximize the FOT’s control of the automation. 

C. SSMO MMOC System Design 

The SSMO MMOC will continue to evolve the baseline of the SMEX GMSEC architecture. Each mission that 
is being integrated into the MMOC currently uses in-house developed automation tools, which have been tailored 
for that mission. In the MMOC, these missions will utilize CAT (rule-based automation tool), ANSR (alert 
notification tool), GREAT (event message logging and archive), and the team chosen telemetry and command 
system. One of the primary reasons for the use of these common components is the ability of the FOT to customize 
the level of automation that is implemented. As described above, this will reduce reliance on the original 
automation software developers and cultivate greater acceptance of the automation by the FOT. Furthermore, 
different levels of automation can easily be implemented for different spacecraft, all configurable by the FOT. 

The design team is currently performing a trade study to select the MMOC T&C system. The top two systems 
under consideration are the INCNG system and the GSFC- developed system ITOS. There are advantages and 
disadvantages to each and a selection will be made in May 2007. 

The Health and Safety automation is comprised of two key elements, the T&C system and the Criteria Action 
Table. The T&C system will monitor limit violations and publish violations through the GMSEC interface. The 
CAT will monitor these messages and react to them, typically paging an operator according to their area of 
responsibility. Operators will be able to monitor the violations through the T&C system, as well as the events 
generated by CAT. 

Automation of satellite loads and some commanding will be performed by T&C procedures, which will run 
during real-time supports. These procedures will monitor telemetry values and execute predefined algorithms to 
verify the current state, transmit command loads, dump buffers, and validate the loads onboard the satellite. 

The XFDS system will be used for generating flight dynamic products. XFDS operates as a service and through 
a number of preconfigured setups, called “actions”, will monitor for product inputs, generate the products through 
interfaces with Matlab, STK, or FreeFlyer, validate, format and distribute the products. 

The integrated scheduler enables XFDS to perform routine product generation. Both a graphical interface and 
GMSEC interface are also available for ad-hoc product generation and enhanced integration into the automation 
system. XFDS has an integrated fail-over capability and can support multiple satellites. 

The planning and scheduling functions within the MMOC will remain on legacy systems. It was determined 
through trade studies to be cost prohibitive to upgrade these systems for each mission. 

D. Design Principles 

Based on FOT experiences with the technologies in the current SMEX MMOC, as well as a survey of other 
automaton technologies and techniques, the following set of principles has been developed as a guide to future 
automation integration in the SSMO MMOC: 

1 . The automation system will be data driven to allow the FOT to manage and evolve the automation as 
their MMOC experiences develop, without needing to involve developers or get software updates. 
This implies the automation logic should be accessible through configurations and not hard-coded 
within the system. The FOT should be able to manage and configure the automation system with a 
‘reasonable’ amount of training. 

2. The automation system will allow for the FOT to easily take control and restart the automation. 
Manual control will be necessary, such as during anomalies. The FOT must have the visibility into 
the automation being performed and the current state of the automation in order to take control. 
Furthermore, when the FOT is ready to return control back to the automated system, the automation 
must be started in the most appropriate state. 

3. The automation system will consist of time-driven and event-driven components. Time-driven 
components will perform predefined automation routines on a schedule. The schedule is computer 
generated and built from various input sources, such as the ground contact schedule. The event- 
driven components will react based on the state of the satellite or system. These components are 
normally in a monitoring role, watching for anomalous conditions or other criteria that warrant a 
response. Both of these systems will be under the control of the FOT. 
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4. The automation will be centrally observable and it is strongly desired that the automation is centrally 
controllable. To be centrally observable implies that a single interface can display the automation 
state of the entire ground system for all the missions and does not require looking at separate 
applications or hosts. To be centrally controllable means the automation can be interrupted or 
restarted at identified points from a single interface, again without interacting with separate 
applications or hosts. 

5. To coordinate activities across multiple missions, a central schedule will control all MMOC 
resources. This will provide operators with an overall view of operations across each mission and the 
potential impacts that schedule changes may have. Having a centralized time-based view is critical, 
since the missions’ activities are independent of each other but make use of common systems. 

6. The automation will run all tlie time , but allow operations to be performed on-top of automation. The 
automation will manage pre-pass setups, pass processing, and post-pass shutdown, as well as monitor 
and perform routine product generation. The operators will be able to interface real-time with the 
satellite in conjunction with the automation, to perform additional duties such as instrument 
commanding or memory loads and dumps. 

7. The ground system components will provide a programmable interface as an alternative to a 
graphical interface. Examples of such interfaces include an Application Programming Interface 
(API), a command line interface, a web services interface, or a GMSEC interface. Graphical 
interfaces are suitable for manual operations, but alternate means of control are required to enable 
automation. 


IV. Conclusion 

The current project completion estimate is December 2008. Specifically, the Wind mission is planned for 
integration by 12/31/2007. The ACE mission is planned for integration six months later by 6/31/2008. Finally, the 
SOHO mission will be integrated into the final MMOC configuration by 12/31/2008. This current schedule supports 
estimated dates that will likely change once a final implementation plan has been developed. 

When the mission integration is complete, the MMOC will be supporting several dissimilar satellites using 
common ground systems components based on the latest information technologies. The authors anticipate enough 
cost savings to allow the TRACE, Wind, ACE and SOHO missions to operate for at least 5 more years and realize 
the return on investment. Additionally, the work done will simplify the integration of future missions enabling new 
missions to take advantage of the automation and operations cost savings. 

There are still challenges to be addressed with the integration of these satellites into the SSMO MMOC. The 
first challenge is standardization across missions. Not only do the hardware and software support systems require 
standardization across the missions, but so do the operating procedures. Both operators and automation require 
established procedures for performing operations, and in order to minimize both FOT training and automation 
development, ideally these operating procedures should be very similar across all the missions. 

The second challenge is the need to initially increase staffing in order to facilitate the move to an automated 
system. The reengineering team is comprised of FOT members who also have everyday operational duties that must 
be fulfilled. It will be difficult to advance the automation without the FOT’s expert knowledge of each satellite. 

Third, as the move is made to empower the FOT to have ownership of the automation, both their duty 
expectations and skill-sets will need to evolve and retraining will be necessary. Despite this challenge, the authors 
believe that having the FOT take ownership of the automation and keeping the automation simple will provide 
numerous benefits. These benefits include quicker adoption of the automation by the FOT, the ability to evolve the 
automation over time without involving software developers, and enabling the FOT to interact and take control of 
the system when required. This approach will not automate the MMOC 100%, but is sufficient to meet our goal of 
assisting the operators while reducing the operational costs. 

Acknowledgments 

This work was performed under NASA Prime Contract NN-G-04-DA01-C and managed by Honeywell 
Technology Solutions, Inc. The authors would like to thank the Honeywell team and GSFC employees who have 
supported this effort. 


8 

American Institute of Aeronautics and Astronautics 



References 

‘Madden, M„ Cary Jr., E., Esposito, T., Parker, J., and Bradley, D., “Lessons Learned from Engineering a Multi-Mission 
Satellite Operations Center,” IEEE Aerospace Engineering Conference, CP0-7803-9546-8/06, IEEE, Big Sky, MT 2006. 

2 Madden, M., Cary Jr., E„ Parker, J., and Bradley, D., “Fleet Integration for Multi-Mission Operations Center,” AIAA Space 
2004 Conference, AIAA, San Diego, CA 2004. 

3 “NASA GSFC Explorer Web Site” [website], URL http://explorers.gsfc.nasa.gov/missions.html [cited June 17, 2004] 

4 “GMSEC Web Site” [website], URL http://gmsec.gsfc.nasa.gov [cited April 24, 2007] 


9 

American Institute of Aeronautics and Astronautics 



